1. Field of the Invention
The present invention relates generally to a Converged Address Book (CAB) service in a Session Initiation Protocol/Internet Protocol (SIP/IP) core network. More particularly, the present invention relates to a method and apparatus for managing communication histories of mobile terminals using a CAB service.
2. Description of the Related Art
A CAB service in an SIP/IP core network is a single network-based address book service for allowing a user to store available address information in various terminals and to access this information with any device at anytime and anyplace, and for synchronizing the address information.
A conceptual structure of CAB proposed by Open Mobile Appliance (OMA) CAB Group includes, as illustrated in FIG. 1, a CAB client 100, a CAB server 120, a contact control server 130, and a eXtended Make-up Language (XML) Document Management Server (XDMS) 140.
The CAB client 100, which communicates with the CAB server 120 on a terminal, transmits, to the CAB server 120, information regarding CAB user authentication, synchronizes a Personal Contact Card (PCC) and a CAB stored in a network storage, and maintains requirements of a CAB user, for example, address subscription, address finding, address sharing, interaction with an old address book, management of user preference, or the like.
The CAB server 120, which is a major network element in the CAB architecture, handles CAB user requirements received from the CAB client 100. A key function of the CAB server 120 includes receiving updated address information from functions such as mutual authentication on a CAB client, storage of CAB addresses, synchronization of address information, and address subscription, and reflecting the updated address information in the address book.
The contact control server 130 is a network element that reflects address subscription/sharing/change and user preference/policy, and its major functions include an address subscription function of withdrawing CAB user preference-related XML documents from a CAB user preference/policy XDMS and receiving a subscribe request from a CAB user, an address share function of applying personal preferences of data received through the address subscription, reflecting the personal preferences in an address book, maintaining subscription state information, and sharing a PCC or a CAB, and an interworking function (IWF) of interworking with the legacy address book system, or exposing an interface to an external enabler.
The XDMS 140 managing user data includes a CAB XDMS for storing a CAB, a CAB user preference/policy XDMS for storing user preference and policy, a CAB Contact Status XDMS for distinguishing CAB users from the existing users, a CAB Contact Share XDMS for storing an address book shared by others, a PCC XDMS for storing PCC information, Communication History XDMS for storing communication history and so forth. Aside from these, the XDMS 140 may include an XDMS for accessing various XDMS functions, and an SIP/IP core network for message routing with entities in an external domain.
An example of communication between a recipient having a plurality of terminals and a sender will be described with reference to FIG. 2. In the example shown in FIG. 2, a recipient having several terminals communicates with a sender in a CAB service. In FIG. 2, a receiving-side user A having a plurality of terminals establishes an audio session in response to a communication request from a sending-side user B 240, which is received at first terminal #1 200 in steps 201, 203 and 205. Here, user B 240 may constitute a user group. After achieving a desired object (e.g. call, Short Message Service (SMS), messenger service, etc.) between a recipient and a sender, the user A closes the session to user B 240 in steps 207 and 209. As the session is closed, a communication history for this communication is recorded in both of the first terminal #1 200 of user A and a terminal of user B 240 in steps 215 and 245. However, in the current CAB service, when a second terminal #2 220 of user A sends a request for session establishment to user B 240, the second terminal #2 220 cannot find the communication history recorded in the first terminal #1 200 of user A, so user A cannot make smooth communication with user B 240 that uses the communication history in step 225. In addition, if the contact address of user B 240 is not stored in a CAB address book, user A cannot initiate communication with user B 240 unless user A checks the communication history of the first terminal #1 200.
As stated above, when a recipient having a plurality of terminals attempts communication with a sender with a second terminal after communicating with the sender using a first terminal, the recipient cannot acquire information about a communication history with the existing sender unless the user checks the communication history using the terminal that first communicated with the sender, and the current CAB service also does not provide this information, causing a great hindrance in smooth communication of users having a plurality of terminals. Therefore, there is a long-felt need for a method capable of collectively managing the communication histories existing in the plurality of terminals in the CAB service.